Subject: Re: [spring] 答复: Re: New Version Notification for draft-lw-spring-sid-allocation-01.txt

From: Peter Psenak <[email-masked]>
Date: Thu, 12 Mar 2015 09:11:16 +0100

On 3/12/15 08:02 , [email-masked] wrote:
>
> Hi Rabah,
>
> If the nexthop learnt from the mapping message is the nexthop to the
> prefix of non SR node,
> as shown in the figure:
>
> The SRMS allocates a SID label 105 to a non SR node LR5,
> SR1 learns the message, and the nexthop of SR1 to LR5 is to R4,
> SR4 and LR5 is a normal IGP adjancency without label.
> When SR1 sending out a packet with a top label 105, the nexthop is to R4,

given that SR is not running on a link between SR1 and SR4, SR1 would 
send packet as unlabeled to R4.

Peter

> R4 receives the mpls packet, but it doesn’t have a label forwarding
> entry, it will drop the packet.
>
> Best Regards.
> Ting
>
> "spring" <[email-masked]> 写于 2015-03-11 18:08:02:
>
>  > >Hi, Please see inline[Rabah]
>  >
>  > De : [email-masked] [mailto:[email-masked]]
>  > Envoyé : mercredi 11 mars 2015 10:33
>  > À : GUEDREZ Rabah IMT/OLN; Peter Psenak (ppsenak); Stefano Previdi
> (sprevidi)
>  > Cc : [email-masked]; spring
>  > Objet : Re: [spring] New Version Notification for draft-lw-spring-
>  > sid-allocation-01.txt
>  >
>  >
>  > Hi rabah，peter，stefano,
>  >
>  > Thanks for your reviews and comments. The SID allocation proposal is
> used to
>  > solve the automatic SID configuration based on the operator's
>  > requirment of zero configuration for the nodes.
>  > It includes the following differences with SRMS：
>  >
>  > 1.  It has a mechanism to ensure the uniqueness of SID allocation.
>  > When two or more SRMNs(SR management nodes described in this draft)
>  > allocate different SIDs to the same prefix,
>  > we provide a method for the SR nodes to choose one of the SID in
> theproposal.
>  >
>  > 2.  The SRMN only allocates SID to SR node in this draft.
>  > I wonder there may be some problem if SRMS can allocates SID to non-
>  > SR node and SR node.
>  >
>  > For example, the SRMS is in charge of mapping a SID( SID A) to a non
> SR node（
>  > node A）originally,
>  > and then SRMS floods the mapping message to SR domain, when a SR
>  > node(node B) receives  the message,
>  > node B learns an entry of SID A with a nexthop, where  the nexthop
>  > is the shortest path to SRMS but not to node A.
>  > Of course the SRMS can be used to allocate a SID（SID C）to a SR
>  > node(node C),
>  > when SR node B learns  this message , it still learns the nexthop is
>  > the shortest path to SRMS，
>  > and in this case，the nexthop should be to node C.
>  > >[Rabah]  No this not true upon the reception of  the mapping SID-A
>  > prefix Z by any SR-Node , the node IGP-SPF will match the SID A
>  > prefix with its routing table and calculate
>  >   the shortest path(exit interface) to that prefix and install an
>  > entry in the NHFE( Next Hop Label   Forwarding Entry).
>  >
>  >
>  > In this proposal, the nexthop is to SR node C.
>  >
>  > 3.  In the allocation TLV described in this draft, it can carry
>  > other SR related configuration such as algorithm, MT number,
>  > and in a TLV, it can carry one or more ip addresses, no matter the
>  > addresses are consecutive or inconsecutive.
>  >
>  > Best Regards.
>  > Ting
>  >
>  > "spring" <[email-masked]> 写于 2015-03-10 21:49:49:
>  >
>  > > The mapping server is attended to bind prefixes and SID of  non
>  > > SPRING nodes, not to configure a SPRING node see https://tools.ietf.
>  > >
> org/html/draft-filsfils-spring-segment-routing-ldp-interop-02#section-4.2
>  > >
>  > > Configuring SPRING nodes can be done manually or via a centralized
> entity,
>  > > The centralized entity can be an SDN controller or an extended
>  > > mapping server, configs can be pushed using OpenFlow or NETCONFIG
> /YANG see
>  > > https://tools.ietf.org/id/draft-litkowski-spring-sr-yang-00.txt
>  > >
>  > > In my opinion we should work on the process of configuring SPRING
>  > > nodes, the architecture(SR-client and SR-controller) and defining
>  > > the minimum configs for a node to function properly.
>  > >
>  > > Nether the proposed draft nor the section on the mapping server
>  > > addressed those requirements.
>  > >
>  > > There are two types of configurations that need to be pushed to
>  > > SPRING nodes  : Required and Optional
>  > > Required configs : are all the information that has global
>  > > signification like node-SID, anycast-SID,++ ..., or when decided to
>  > > use the same SRGB on all the SPRING nodes, those config must be done
>  > > manually or pushed from centralized entity.
>  > > Optional configs : all the decision that can be made locally by the
>  > > "SR-client"  like assigning Adj-SIDs to the node interfaces.
>  > >
>  > >
>  > > -----Message d'origine-----
>  > > De : spring [mailto:[email-masked]] De la part de Stefano
>  > > Previdi (sprevidi)
>  > > Envoyé : mardi 10 mars 2015 13:07
>  > > À : Peter Psenak (ppsenak)
>  > > Cc : [email-masked]; <[email-masked]>
>  > > Objet : Re: [spring] New Version Notification for draft-lw-spring-
>  > > sid-allocation-01.txt
>  > >
>  > > I agree. We already have interop tests done on the SRMS so what is
>  > > the real added value of another proposal ?
>  > >
>  > > s.
>  > >
>  > >
>  > > On Mar 10, 2015, at 12:46 PM, Peter Psenak <[email-masked]> wrote:
>  > >
>  > > > Ting,
>  > > >
>  > > > there is a concept of SR Mapping Server, which can be used to
>  > > advertise SIDs for prefixes from the central place.
>  > > >
>  > > > draft-ietf-ospf-segment-routing-extensions defines the OSPF
>  > > Extended Prefix Range TLV in section 4 which is used to advertise
>  > > the SID mappings by SRMS. Similarly ISIS SR drafts defines a similar
>  > > mechanism in ISIS. There are already implementations that support SRMS.
>  > > >
>  > > > What you defined in your draft looks very similar to SRMS and we
>  > > definitely do not need two different ways to achieve the same goal.
>  > > >
>  > > > regards,
>  > > > Peter
>  > > >
>  > > > On 3/10/15 07:02 , [email-masked] wrote:
>  > > >>
>  > > >> Hi all,
>  > > >>
>  > > >> New version of SID Allocation has been published and description
> has
>  > > >> been revised according to comments from the mailing list.
>  > > >> Comments are welcome and discussions in Dallas are expected.
>  > > >>
>  > > >> Best Regards.
>  > > >> Ting
>  > > >> ----- 转发人 廖婷038768/user/zte_ltd 时间 2015-03-10 08:48 -----
>  > > >>
>  > > >> [email-masked] 写于 2015-03-09 14:39:17:
>  > > >>
>  > > >> >
>  > > >> > A new version of I-D, draft-lw-spring-sid-allocation-01.txt
>  > > >> > has been successfully submitted by Fangwei Hu and posted to the
>  > > >> > IETF repository.
>  > > >> >
>  > > >> > Name:      draft-lw-spring-sid-allocation
>  > > >> > Revision:   01
>  > > >> > Title:      SPRING SID Allocation
>  > > >> > Document date:   2015-03-08
>  > > >> > Group:      Individual Submission
>  > > >> > Pages:      12
>  > > >> > URL:
>   http://www.ietf.org/internet-drafts/draft-lw-spring-
>  > > >> > sid-allocation-01.txt
>  > > >> > Status:         https://datatracker.ietf.org/doc/draft-lw-spring-
>  > > >> > sid-allocation/
>  > > >> > Htmlized:
>  > > >> http://tools.ietf.org/html/draft-lw-spring-sid-allocation-01
>  > > >> > Diff:           http://www.ietf.org/rfcdiff?url2=draft-lw-spring-
>  > > >> > sid-allocation-01
>  > > >> >
>  > > >> > Abstract:
>  > > >> >    Segment Routing (SR) allows for a flexible definition of
> end-to-end
>  > > >> >    paths within IGP topologies by encoding paths as sequences of
>  > > >> >    topological sub-paths, called "segments".  These segments are
>  > > >> >    advertised by the link-state routing protocols (IS-IS and
>  > OSPF).  And
>  > > >> >    a segment is identified by a Segment Routing ID (SID).
>  > This document
>  > > >> >    proposes a method to reduce the SID configuration in a SR
> domain.
>  > > >> >    Only the selected SR nodes which named Segment Routing
> Management
>  > > >> >    Nodes (SRMNs) are configured by NMS, while other SRs in the
> domain
>  > > >> >    need zero-SR-configuration.
>  > > >> >
>  > > >> >
>  > > >> >
>  > > >> >
>  > > >> > Please note that it may take a couple of minutes from the time of
>  > > >> submission
>  > > >> > until the htmlized version and diff are available at
> tools.ietf.org.
>  > > >> >
>  > > >> > The IETF Secretariat
>  > > >> >
>  > > >>
>  > > >>
>  > > >> _______________________________________________
>  > > >> spring mailing list
>  > > >> [email-masked]
>  > > >> https://www.ietf.org/mailman/listinfo/spring
>  > > >>
>  > > >
>  > > > _______________________________________________
>  > > > spring mailing list
>  > > > [email-masked]
>  > > > https://www.ietf.org/mailman/listinfo/spring
>  > >
>  > > _______________________________________________
>  > > spring mailing list
>  > > [email-masked]
>  > > 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
>  > > [email-masked]
>  > > 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
>  > [email-masked]
>  > https://www.ietf.org/mailman/listinfo/spring