Hi Chairs,

I currently have some issue with the anycast section of the draft. Based on the 
discussion  we had during the WG session (through Pushpasis's presentation), it 
looks that the anycast section is not enough explained (what is the problem 
behind ...) and using a "MUST" for mandating "common SRGB" is too restrictive 
to me as it was decided by the WG to make the SR architecture working with 
different SRGB per node.
I'm completely in favor of using "common SRGB" between anycast nodes as short 
term solution if possible, but working on general solution is also necessary.

Some more explanations are necessary, and a recommendation rather than using a 
MUST would be better.

PS : also the anycast draft refers to N-bit unset which is an encoding 
reference and so does not really make sense in this draft, possible solutions :
- move the statement to ISIS and OSPF draft
- be more generic on explaining the constraint (no more reference to encoding)


Regards,

Stephane


-----Original Message-----
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of John G.Scudder
Sent: Wednesday, July 22, 2015 15:24
To: spring@ietf.org
Cc: isis...@ietf.org
Subject: [spring] working group last call for draft-ietf-spring-segment-routing

[re-send with correct address for isis-wg]

Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in 
replies per the reply-to):

As we discussed at the SPRING meeting yesterday, working group last call has 
been requested for draft-ietf-spring-segment-routing. Please reply to the list 
with your comments, including although not limited to whether or not you 
support advancing the document to RFC. Non-authors are especially encouraged to 
comment.

In consideration of the fact that a number of WG calls are going on 
concurrently, we will end the call on August 31, 2015. 

Authors, please indicate whether you are aware of any relevant IPR and if so, 
whether it has been disclosed. (Please do this even if you've done it before, 
thanks for your help.)

Thanks,

--Bruno and John

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to